The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
It is often useful to know the execution history of a program to analyze the underlying software and resolve defects and performance issues. Programs analyzed can be single threaded programs or be complex multithreaded execution entities.
Tools for analyzing programs include debuggers that attach to a program to perform step-by-step or breakpoint-by-breakpoint execution to examine the current contents of program data structures at a particular step or breakpoint. Although this approach gives a peek into the state of the program at an instant of the program's execution, the approach provides no history of execution. Despite the lack of execution history, these type of debuggers may be useful for analyzing simple programs. However for analyzing complex programs on live production systems, the lack of execution history impairs the usefulness of these types of debuggers as a tool for analyzing programs.
Programs sometimes store trace records in persistent storage, such as files on disks that capture the execution history. However, this approach involves significant runtime overhead. The overhead causes programmers to restrict tracing to such a degree that the ability to effectively perform first pass diagnosis when a problem occurs is substantially impaired.
Based on the foregoing, there is clearly a need to provide a mechanism that allows tracing to be implemented in a way that reduces overhead.